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(57) Abstract: This invention relates to the field of IP telephony. More particularly, this invention is a method and system for select- 
ing gateways for routing calls through a packet-based telecommunications network interconnected with a public telecommunications 
network. This invention is a method and system for dynamically detecting available gateways (110a, 110b), dynamically removing 
failed or unavailable gateways (1 10a, 1 10b), and automatically recovering failed or unavailable gateways after a predetermined pe- 
riod of time. An embodiment of this invention comprises two user agents (102, 103) within two telephony systems (114a, 114b) that 
are connected to an IP network (1 12); a plurality of gateways (1 10a, 110b); an IP telephony proxy server (106); an IP redirect server 
(104); and a network management system (108). 
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METHOD AND SYSTEM FOR DYNAMIC GATEWAY SELECTION 
IN AN IP TELEPHONY NETWORK 



10 BACKGROUND OF THE INVENTION 
Field of the Invention 

The present inveniion relates generally to the field of IP telephony, and more particularly 
to a method and system for selecting gateway(s) for routmg calls through a packet-based 
telecommunications network interconnected with a public telecommunications network. 
1 5 Acronyms 

The written description herein uses a number of acronyms to refer to various services, 
messages and system components. Although generally known, use of several of these acronyms 
is not strictly standardized in the art. For purposes of this discussion, several acronyms wiU be 
defined as follows: 

20 Dynamic Gateway Selection (DGS) - a process employed by a network server and a 

Redirect Server (RS) to allow calls to be routed to an egress gateway. 
Egress (Destination) and Ingress (Origination) Gateways - gateways connecting an 
internet protocol network to a PSTN, PBX or other network. 

Network Management System (NMS) - performs a variety of functions, including 
25 receiving and storing status changes to destination or egress gateways. 

Description of the Prior Art 

Internet telephony provides real-time delivery of voice, and other multimedia data, 
between two or more panics across a network employing Internet protocols (IP). Internet 
telephony is session-based rather than connection-based. That is, Internet telephony uses virtual 
30 connections or circuits lo pass data between two nodes. These connections between the nodes 
are termed "virmal circuits'' to distinguish them from dedicated circuits of conventional 
networks. 

. 1 
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While IP lelephony offers benefits to both users and carriers in terms of costs and 
versatiliiy of media carried, there are a substantial amount of traditional telephones being 
serviced by the Public Switched Telephone Network (PSTN). The PSTN provides users with 
dedicated, end-to-end circuit connections for the duration (3f each call. Circuits are reserved 
between an originating switch and a terminating switch based on a called pany number. 

However, because of the popularity of the Internet, many public telecommunication^ 
networks now carry significantly more IP data traffic than voice data traffic. Publi^ 
telecommunications networks, optimized for voice traffic, are ill-equipped to handle increasing 
data traffic volumes. The growth in IP data ttal^ic coupled with customer demands for integrated 
voice and data services at lower costs has led to the adoption of IP as the prefenred protocols for 
carrying both voice and data traffic between originating and terminating switches of the public 
telecommunications network. 

Accordingly, in order for IP based telephony services to become broadly accepted by 
users of traditional telephones, it is necessary to interface the IP telephony network >yith the 
existing PSTN and with private PBX phone networks. To permit this mode of operation,; a 
packet-based network, such as the Internet, must interface directly with public telephone 
networks and operate as a bridge between originating and destination switches of such networks. 

Media streams which originate from a public network must be capable of being 
transported through the packet-switched IP network and tenninate at the same or different pubUc 
network. This type of interfacing is performed by gateways which intertace the signaling and 
bearer paths between the two networks. Therefore, Internet gateways perform code and protoco^l 
conversion between two otherwise incompatible networks to provide links necessary to send 
packets between the two different networks and thus make network-to-network connections 
possible. To assure overall system reliability it is crucial that the gateways arc reliable and their 
availabUity, especially destination or egress gateways, be monitored for quickly and efficiently 
selecting an available gateway. 



STTMMARY OF THE INVKNTTON 

In accordance with the principles of the invention, a method and system are provided by 
which an egress (i.e., destination) gateway is dynamically selected to establish a communication 
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session over a path supported at least in pan by an IP telephony nei^^ork and a PSTM. PBX or. 
other net^vork. A redirect server (RS) in concen with a network management system (NMS) 
employs a gateway selection methodology which includes recording egress gateways which are 
not available due to several reasons, such as having timed out. or having a malfunction, i.e., 
failure status. 

In one embodiment of the present invention, a method is provided for dynajnaically 
selecting an egress gateway to allow a call to be completed in a communication session over a 
path supported at least in part by an IP telephony network and a PSTN, PBX or other network. 
The IP telephony network includes a plurality of ingress and egress gateways, at least one 
Session Initiation Protocol (SIP) proxy server (SPS) and at least one redirect server (RS). A 
dynamic gateway selection (DGS) feature is always active and is typically invoked whenever a 
source user agent (SUA) initiates a call attempt by sending a session participation request to the 

SPS. ' 

The prefeixed method generally includes the steps of: receiving a call setup request at tii^ 
SPS from the SUA . The SPS fonvards the request to the RS to obtain information of destination 
gateways. The R responds to the SIP session participation request with either a redirection 
response or a request failure response. The RS redirection response includes a routing list. The 
routing list is a list of egress (i.e., destination) gateways that arc determined to be in-service., 
Upon receipt of a redirection response from the RS. the SPS proxies the session participation 
request to a first destination gateway in the routing list. Othenvtse, the RS returns a feilure 
response which is sent to the SUA. The failure response is an indication that there are no 
destination gateways having an in-service status. 

When the SPS proxies the request to a destination gateway, the SPS waits for a final 
response from the selected destination gateway. The SPS will either receive a fmal response or 
time-out. When the SPS receives a fmal response from the destination gateway, the SPS proxies 
the fmal response to the SUA, awaits an acknowledgment and proxies the acknowledgment. 
Otherwise, when the SPS times-out waiting for a fmal response from the destination gateway, 
the SPS re-sends the request a predetermined number of times. If the SPS times-out for a final 
time, the SPS sends the session panicipation request to the next destination gateway in the 
routing list provided by the RS. 
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The process of sending a request a predetermined number of times is repealed for the 
next destination gateway in the routing iisi until one of the following occurs: (1) a success 
response is returned; (2) the SPS times-oux waiting for a final response, as described above with 
respect to the first destination gateway in the routing list: (3) the SPS receives an unsuccessful 
fmaL non-server failure response from the currently selected destination gateway; or (4) the 
destination gateway returns a server failure response, in which case the SPS informs the RS of 
the destination gateway failure. 

In case of the second to founh situations, the SPS sends the session participation request 
to other destination gateways in the routing list provided by the RS. For each destination 
gateway that returns a gateway failure response to the SPS, the destination gateway is recorded 
as an out-of-service destination gateway in the RS and is dynamically removed from the routing 
list- Therefore, subsequent requests are not sent to destination gateways which are recorded as 
out-of-service destination gateways in the RS until after a predetermined amount of time. After 
the predetermined amount of time has elapsed, the RS auromaxically recovers failed or out-of- 
service pathways and issues a report to a network management system (NMS) indicating that the 
destination gateway is back in service. Table stmctures, stored within the RS, are updated on 
a real-time basis when it is determined that a gateway is out-of-service or back in-service. When 
the session participation request has been sent to all destination gateways and no successfiil 
response is received, the SPS returns a final response to the originating agent or calling party 
indicating that a call cannot be made. f 
In an alternative method, availability of destination gateways is determined using a ping 
method. In this method, gateway availability is determined by sending at least one packet to 
each destination gateway to ascertain whether the destination gateway is available, or in-service. 
If the destination gateway is in-service, it transmits an ACK message. If an ACK message is 
not received after a predetermined period of time, the destination gateway (DGW) is determined 
to be unavailable. The ping method preferably queries each destination gateway one-by-one and 
updates gateway information tables by recording the status of each destination gateway. 

The present invention thereby provides several ftinctions, including: (1) dynamic 
detection of failed and unavailable gateways; (2) dynamic removal of failed and unavailable 
gateway(s) from a routing list, gateway information table, etc., after a predetermined period of 
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lime; and (3) automatic recovery of failed and unavailable gateways by updating gateway status - • 
tables after a predetemimed period of time. 

RRTRF DESCPTPTTON OF TMTT. DRAWINGS 

Various preferred embodimems are described herein wth reference lo ihe accompanying . . 

drawings, in which: 

FIG. 1 is a block diagram of a preferred embodiment of the present invention; 

FIG. 2 is a flowchart illustrating signaling and call setup procedures according to the ■ 

embodiment of FIG. 1 ; 

FIG. 3 is a call flow diagram illustrating the signaling and call setup procedures 

according to the embodiment of FIG. 1 ; and 

FIG. 4 is a flowchart illustrating an alternate embodiment of the present invention. 

HF^TAILED pFSrRTPTTQN OF THE PRF ffFRRED EMBODIMENTS 

Preferred embodiments of the present invention will now be described with reference tO' 
the figures where like reference numbers indicate identical or similar elements. It will be 
apparent to persons skilled in the relevant art that the preseivt invention can operate on many 
different types of networks without departing from the scope of the present invention. In the 
preferred embodiments described herein, the I? telephony network is preferably the Internet. 
Other examples of networks which could be used include leased lines, frame relay, and 
asynchronous transfer mode (ATM) networks. 

The present invention provides a method and system for selecting an egress or 
destination gateway to establish a communication session over a path supported at least in part 
by an IP telephony network, such as a WAN, and a PSTN, PBX or other network. The method 

further determines the status of a destination gateway, particularly, as being cither in-service or 
out-of-service, and automatically brings a destination gateway back into service from an out-of- 

service state after a predetermined amount of time. 

Referring now lo the drawings, and first to FIG. 1, a system according to a preferred 

embodiment of the present invention is designated generally by reference numeral 10. System 

10 is a telephony network system and includes a first public switched telephone network (PSTN) 
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U..erfa=d.o a second PS™ lUK TH. fir. PSTN U 4a include a .ource us„ ag^nUSU^ 
.0.. U.. c« a.en. .hicK cH^na^s a session par.cipa.ion «,u... ^^^^^^ 
U4b includes a called parry des.ina.ion user agenr ^DUA .03), Tire Inreme. 
redireaserv.r(RS) ,04. an SIP proxy server (SPS, 106.aNe.v,or.Managen,enr.ys««(NMS 
,08. and desUnarion ga.e.ays (DOWs, „0a. „0b. W,ile o.y rwo OGWs are shown, one o 
ordinary sHU in .he an .1.1 reco.ni« .ha. addirional DOWs may be P-ded. rhe ^ 4 
suppons a „ manage^en. flmcUon which «ac.s *e s.rus ol .he DOWs, The NMS m 
recL and stores al, s.n.s changes regarding DOWs 1.0., 10b. S«us changes are repor^ 
» *eNMS .08 by *e RS 104 via *e SPS 106. SPS .06 acs as boflr a server and Cent for 4e 
purpose of n«Wr.g re.ues.s on behalf of orher clicn.s. SPS .06 provides proxy sen,«r and 

, fimrrinn^ SPS 106 may be a SIP proxy server or an H.323 
gateway resource rnanagemem functions, a luo m^^y ^ 

'''''Te nr«hod of *e presenr invention (U., dynamic ga,e..y selecion (DOS) ar,d 
renrcval) is perfo^ed by *e SPS 106 and RS 104 ur con»x. wi* .he KMS 108 in order io 
allow calls to be rou«d,ooneof*e DOWs 1.0a, ..Ob. The dynamic gareway selecUon and 
removal teamre Is particularly invoked upon receipt by me RS 104 of a session parUcipaUo. 
request. The SUA 102 initiates a call attempt to .xa^i. the session participation request » the 
SPS 106. Accordingly, an attempt is made to establish a communicaUon session between die 
SUA 102 located in the f,r.,t PSTN 1 14a and the called par^, destination device (DUA) 103 
located in the second PSTN 114b. PSTN lUaand u 4b are bridged via *eln«me. 112, \ 
FIG. 2 is a flowchart Ulustraung the call rouring logic for establishing a communication 
session in accordance with the n,ethodology of .he presem Invention. At step 702, a u^er 
initia.es a call attempt by sending a session participa.ion request <i.e., an INVITE request) to the 
SPS 106. When the INVITE request is an initial request the SPS 106 forwards the initial 
njVrTErequesttotheRS 104 for routing instructions at step 704. At step 705. it is determined 
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whether there is at least one DGW that can satLsly the request. If so. at step 706. the RS 104 
responds to the SPS 106 query with arouting list. i.e.. a list of candidate DGWs that can handle 
the call. The RS 104 supplies ihe routing list from a gateway information table stored therein. 

In the event the RS 104 determines that there are no DGWs that can satisfy the INVITE 
request, at Step 705, . request failure response is returned to the SUA 102. at step 707. Upon 
receiving the routing list, the SPS 106 proxies the INVITE request to one of the DGWs llOa.^ 
1 10b. At step 708. the SPS 106 selects the first DGW I lOa in the routing list to determine its 
serviceability and/or availability stams. Steps 710 and 712 determine whether the currently 
selected DGW 1 10a from the routing list is in a failure state or has timed out. Specifically, ai 
step 710, a determination is made concerning whether the DGW I lOa returns a failure response 
(i.e., out-of-service response). If there is a failure response at step 710, the SPS 106 reports the 
gateway fei:'re- the RS 104 at step 714. The RS 104 marks the selected DGW 1 10a as an out- 
of-servic«- Uestiration gateway in a gateway infonnation table stored in the RS 104. at step 716. 

In addition, the SPS 106 sends a message, (i.e., Sitnple Network Management Protocol 
(SNMP) trap) to the NMS 108 indicating a destination gateway failure. The SPS 106 then 
selects the next DOW 1 10b in the routing list, at step 718. Control then returns to step 710 to 
determine the availability of the next selected DGW 1 1 Ob; that is, whether the next selected 
gateway 1 lOb is in a failure state or has timed out. If the next selected DGW I lOb returns either 
a failure response at step 7 10, or limes-out at step 712, then steps 71 4-7 1 8 are repeated. In short, 
the process of selecting a gateway firom the routing list and detemiining whether it is in a faUure 
state or has timed out is repeated until a DGW is found from the routing list which accepts a cair 
wiih a success response at .step 720. When a success response is received, the SPS 106 forwards 
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10 



15 



Che response to the calling user SUA 102 at srep 722. The media stream for the call is then sex' 
up at step 724 to establish a communication link between the SUA 102 and DUA 103. 

FIG. 3 is a call routing (low diagram illustrating in greater detail the call routing logic 
procedure described above with reference to FIG. 2. Table 1 below lists the INVITE required 
parameter fields in the preferred embodiment when a SUM 02 initiates a call attempt by sending 
a session participation request (i.e.. an INVITE request) to the SPS 106 (See FIG.I, item I and 
FIG. 3, step "'a"). 

Table I 



Parameter 


Usage 


Request-Line 


Contains the method (e.g., INVITE), Request Uniform Resource 
Identifier (i.e., Request-URI) of the SPS and protocol version 


To 


Contains the address of the recipient of the request 


From 


Contains the address of the initiator of the request 


Call-ID 


Uniquely identifies the invitation 


Cseq 


Contains the request method and a decimal sequence number 
chosen by the requesting diem, unique within a smgle value of 
the Call-ID 


Via 


Indicates the path taken by the request so far 



The SIP INVITE is addressed to the called party DUA 103 at a proxy address at the SPS 
106. The SIP INVITE specifies the real IP address of the DUA 103. Upon receipt of the SIP 
INVITE, the SPS 106 sends a 100 trying message to the ingress or origination gateway 105 
(FIG. 3, step "b"). Table 2 lists the mandatory fields associated with the 100 trying response 
message in the preferred embodiment. 



Table 2 



Parameter 



Usage 



□ 
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Status-Line 


Status Code = 100. Reason phrase and protocol version 


To 


Content copied from the original request message 


From 


Content copied from xho original request message 


Call-ID 


Content copies from the original request message 


Cseq 


Content copies from the original request message 


Via 


Indicates the path taken by the request so far. Add the received- 
tag parameter if the previous address is incorrect in the via header 
fiJld 



The SPS 106 counts the number of INVITE requests received. When a received request 
message does not contain a route header field, it is determined to be an initial INVITE request 
message. In such a case, the SPS 106 performs the following steps: (1) if a Topmost Via Header 
(TVH) source address is incorrect, adds a "Received" parameter (or replaces the existing one if 
there is one) with the source package to the Via header field inserted by the previous hop; (2) 
generates an internal Call-ID; or (3) for>vards the requested message to the RS 1 04 (See FIG. 1, 
item 2 and FIG. 3, step "c"). Table 3 lists the required fields in the RS INVITE request message. 

Table 3 



Parameter 


Usage 


Status-Line 


Content copied from the original request message 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Internally generated Call-l 


Cseq 


Content copied from the original request message 


Via 


Add the received tag 



In response to receiving the RS INVITE request message from the SPS 1 06, the RS 1 04 
performs the following: {I) counts the number of INVITE messages received; and (2) determines 
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thax the Iser portion of Request Uaifonn Resource Identifier (i.e.. (Request-URJ) is less xhan or 
equal to 1 5 digits and does not contain a leading 0 orl . The gateway information table stored 
in RSI 04 is used to create an updated routing list. 

For example, when a gateway address is marked as oui-of-setvice in the gateway 
information table stored in RS 104 and its associated time value is zero, the gateway address is 
not added to the routing list. When the gateway address is marked as out-of-service in the 
gateway information table and its associated time value is greater than the current absolute RS 
time, the gateway address is not added to the routing list. When the gateway address is marked 
as out-of-service in the gateway inlbrmation table and its associated time value is less than or 
equal to the current absolute RS time, the gateway address is added to the routing list and the 
gateway address is marked as in-service in the gateway information table. The RS 104 also sends 
a message, i.e., the Simple Network Management Protocol (SNMP) trap, to the NMS 108 
indicating that the DG W is in-service. If there is only one gateway in the routing list, the RS 104 
will send a 302 response message back to the SPS 106 (See FIG. 1 , item 3 and FIG. Is step "d"). 
The RS 104 increments a counter which counts the number of 3xx messages sent. Table 4 lists 
the required fields in the 3xx (302 in the present case) response message and an example of the 
contact address list. 

Table 4 



Parameter 


Usage 


Status-Line 


Status Code = 302, Reason phrase and protocol version 


To 


Content copied from the Original INVITE request 


From 


Content copied from the Original INVITE request 


CalHD 


I Content copied from the Original INVITE request 



10 
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Cseq 


Content copied from the Original INVITE request 


Via 


Content copied from ihe Original INVITE request 


Coniaci 


Multiple eatcway addresses 



11 
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Table 5 lists the required fields in the SNMP trap message to the NMS. 

Table 5 



Parameter 


Usage 


Protocol Data 
Unit (rUU) lype 


Indicates that this is a Trap PD 


Enterprise 


Identifies the network-management subsystem that generated 
the tran Its value is taken from sysObjectlD in the system 
Group 


Ageni-addr 


The IP address of the object generating the trap 


Generic-trap 


6 = enterpriseSpecific. This value signifies that the sending 
protocol entity recognizes that some enterprise-specific event 
has occurred. The specific-trap field indicates the type of 
trap 


Specific-rrap 


A code that indicate more specifically the nature of the trap 


Time-stamp 


The time between the last (re)initializauon of the network 
entity that issued the trap and the generation of the trap 


Variable bindings 


The address of the gateway that remmed the 5xx response 
and status (iri-service) 



In the case where there is more than one gateway in the routing list, the RS 104 sends a 
300 response message, instead of a 302 response message for a single gateway, back to the SPS 
106. For a 300 response, the RS 1 04 also counts the number of 3xx responses sent. Table 6 lists 
the required fields in the 300 response message and an example of the contact address list. 



12 
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Table 6 



Parameter 


Usage 


Status-Line 


Status Code = 300. Reason phrase and protocol version 


To 


Same as ihe original INVITE 


From 


Content copied from the Original INVITE request 


Call-ID 


Content copied from the Original INVITE request 


Cseq 


Content copied from the Original INVITE request 


Via 


Content copied from the Original INVITE request 


Contact 


Multiple reachable addresses 



The SPS 106 counts the number of routing responses received from the RS 104. The 
SPS 106 sends an INVITE to the first DGW 1 10a, and inserts the •^ser=phone" header in each 
contact list address (See FIG. 1 , item 4 and FIG. 3, step "e"). Table 7 lists the required fields of 
the INVITE request sent from the SPS 106 to the DGW 1 1 Oa. 

Table 7 



Parameter 


Usage 


Request-Line 


Contains the method (e.g., INVITE), Request-URI using the 
gateway from the top of the unused coniacT list and protocol 
version 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Content copied from the original request message 


Cseq 


Content copied from the original request message 


Via 


Add the NS URL to the top 


Record Route 


Request-URI of the NS 



13 
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The SPS 106 may receive a 100 trying response (see FTG. 3, step "f) or a 180 ringing- 
respor^se from the DGW 1 1 Oa (See FIG. 3. step --g"). Table 8 lists the required fields of the 180; 
ringing response. 

Table 8 



Parameter 


Usage 


Status-Line 


Status Code = 180, Reason phrase and protocol version 


To . 


Same as the original INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Via 


Same as the INVITE request sent to the Egress Gateway 



After receiving the 180 ringing response from the DGW 1 10a, the SPS 106 removes 
itself from the top of the Via field, re-starts the invite User Agent (UA) timer if it exists, and 
forwards the 180 ringing response to the ingress gateway (See FIG. 3, step "g"). The response 
message is sent to the address indicated in the Via header field. Table 9 lists the required 
message elements. 

Table 9 



Parameter 


Usage ^ : — 


Status Line 


Content copied from the 180 response received from the gateway 


To 


Content copied from the 180 response received from the gateway 


From 


Content copied from the 180 response received from the gateway 


Call-ID 


Content copied from the 180 response received from the gateway 


Cseq 


Content copied from the 180 response received from the gateway 


Via 


Content copied from the 180 response received with the removal 

ofiheNSURL- 



14 
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TXTVTTP re^nonse (i e -^00 OK respoase) from the DGW 1 10a (See 
The SPS receives an rNVi i b response i^i.c. -w r 

FIG. 3. step "hi"). Table 10 li.ts rhe required fields in the INVITE rriessage. 

Table 10 



Parameter 


Usage . ^ ■ 


Status Line 


dt^tiK Code - 200, Reason phrase and protocol version 


To 


Same as the original INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sem to the Egress Gateway 


Record Route 


RequesT-URJ of the NS 


ConTaci 


The reachable address of the Egress Gateway 



After receiving the 200 OK response from the DGW 1 10a, the SPS 106 performs the 
following step.: . I) cancels the invite UA timer, if it exists; (2) removes the SPS URL ftom the 
Topmost Vi. Header (TMVH) field; (3) adds the next hop's Request-URI at the top of the 
record-route header field when either of the following conditions are met: a) there is no contact 
header field in the 200 OK response, or b) the SPS URL is on the top entry of the record-route 
header field; (4) counts the number of 200 INVITE responses sent by the SPS 106; and (5) the 
SPS 106 starts the aCK timer. The SPS 106 forwards the INVITE response (i.e., 200 OK 
response) to the ingress gateway (See FIG. 3, step "hi"). Table 1 1 lists the required headers in 
the INVITE response. 
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Table 1 1 



10 



Parameter 


Usage ' — 


Staius-Line 


Status Code = 200, Reason phrase and protocol version 


To 


Same as ine original xin v x i c i^h'^^'^ ^ p 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Via ' 


Content from the INVITE request sent to the Egress Gateway 


Record Route 


Request-URIoftheNS 


Contact 


The reachable address of the Egress Gateway 



Tlie SPS 106 receives an ACK response from the ingress gateway and stops the ACK 
timer. The SPS 106 counts the number of ACK response messages received by the SPS 106. 
Table 12 lists the required headers of the ACK response (See Fig. 3, step "k"). 

Table 12 



Parameter 


Usage 


Request-Line 


Contains method (e.g., ACK), Request-URI of the NS and 
protocol version ' ^ — 


To 


Same as the original INVITE plus the tag 


From 


Same as the original INVITE 


Call-ID 


Same as the original INVITE 


Cseq 


Same sequence number as the original INVITE 


Via 


UA originated 



The received ACK response may contain a route header field. The SPS 106 either 
proxies the ACK response using the address in the route header or uses the address in the "To" 
header to determine whether lo proxy the ACK response or consume the ACK response. The 
ACK response will be consumed when the "To" header address is equal to the SPS address, and 
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» route h=a.« exis. in .he aCK r«pc^.. When the SPS .06 determine, that the ACK 
^pon. shouM .e pto.ied. the SPS i06 perfonns the foUcwin^: U) .he SPS 106 ^ the 
ACK-s addxess to the top of the Via field: (2) the SPS 1 06 tentove. the top address ftotn the 
.ute header field. ,3) the Re,.es.-Uia is set to 4,0 add«ss located at the top of the route header . 
field; and (4) *e ACK message is forwarded to the DGW 1 10a based on the top address in .he 
„«e header field if it exists or based on the call context's DOW information (See FIG. 3. step^ 
«n. Accordingly, the DGW UOa U selected as the available gateway for completing the call.' 
tf the DGW UOa is determined to be tmavailable, tite same method omlined above is used to 
determine if DGW UOb is available. If neither DGW is available, a message is sem to the SUA 

Table 13 IlststheparametersoftheAClCrequestmesaage 
102 that the call cannot be completed. Table ustsme p<u 

senttotheDGW nOa. 

Table 13 



Parameter , 


Usage ^ 


Request-Line 


Contains method (e.g., aCK), Request-URI is copied from the 
top list of Route header field and protocol version 


To 


Content copied from the ACK received from the Ingress 
Gateway '■ -— 


From 


Content copied from the ACK received from the Ingress 
Gateway . — 


Call-ID 


Content copied IVom the ACK received from the Ingress 
Gateway — — 


Cseq 


Content copied from the ACK received from the Ingress 
Gateway 


Via 


■ UA orieinated with the NS URL added to the top of Via field 



embodiment, gateway availability is detennined by sending at lean one packet to each 
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destination gateway to ascertain whether the destination gateway is available, or in-service. 
Accordingly, if the destination gateway is in-seivice. it transmits an ACK message. If an ACK 
message is not received after a predetermmed period of time, the DGW is determined to be 
unavailable. The ping method preferably queries each destination gateway one-by-one and 
updates a gateway informaiioD table by recording the status of each gateway. For example, if 
the ACK message is received, the DGW is then checked to determine if it is available. If it is 
available, its address is stored in a gateway information table, and the proces.s repeats for the next 
DGW. 

FIG. 4 is a flowchart illustrating the methodology of an alternate embodiment of the 
present invention, i.e., the ping method. A counter is initialized at step 800 to indicate the 
currently selected destination gateway from the routing list (i.e., i-1 to the number of gatev^ys 
in the routing list). In step 802, a message is transmitted from a server (e.g. proxy server, 
redirect server) to the ith destination gateway for the purpose of obtaining a response. In step 
804 the server awaits a response from the ith destination gateway. Step 806 is a determmation 
step to determine whether a response was received from the ith destination gateway. If a 
response is not received within a predetermined amount of time, the process continues to step 
807 where the ith gateway is marked as out of service or unavailable. In step 808, it is 
determined whether there are additional destination gateways to check from the routing list. If 
not, the process terminates at step 810. Otherwise, the counter is incremented to select a 
succeeding destination gateway from the routing list at step 812. 

Steps 802-806 are then repeated to check the response and/or availability of the 
succeeding (i.e. ith + 1 ) destination gateway from the routing list, tf it is determined at step 806 
that a response is received within the predetermined time, the process continues to step 814 
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Where u U *en tether d«en..ned whe^er the respoading dcsU,>a,icr. gareway U av=U,3b.e or 
If Che destinauon g=-»ay is .0. available. *e process reruns .0 S«P 807 where .he 
desdnadon gateway is marked =. our of service or unavailable. In srep 808. it is then de.err.ined 
whether *ere are additional desdnaaon ga.eways to check ftom Ae routing list. If so. s«ps 802- ^ 
806 are repeated for the succeeding destination gateway. Otherwise, if i. is de.er»ined at step 
814 thatthe responding destination gateway is available, the process continues a. step 816 where 
the destination gateway is tnarked as available in a gateway stan. .able. The process re»ns io 
srep 808 to determine if tee are additional destination gateways te be checked in the routing 



list. 



What has been described herein is merely illustrative of the application of the principles 
of the presciit invention. For exanxple. the functions described above for operating the present 
invention i' illustration purposes only. Other arrangements and methods may be 
implemen-ed b'. those skilled in the art without depaning from the scope and spirit of the 



invention. 
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wp Ay r«K rT AIMED IS: 

1 1 . A method for routing calls to a destination gateway to establish a communication 

2 session call in a telecommunications network over a path supponed at least in part by a telephone 

3 network and an IP network, said IP network including a plurality of ingress and destination 

4 gateways, at least one proxy server, and at least one redirect server (RS). said method comprising 

5 the steps of: 

6 . a) receiving a call semp request at the at least one proxy server from a source user 

7 agent; 

8 b) forwarding the received call setup request to the redirect server to obtairi 

9 routing information; 

^0 c) responding to the forwarded call semp request received at the redirect servei 

11 by returning said routing information or a request feilure response; 

1 2 d) proxying the call setup request by the at least one proxy server to a destinatioi 

1 3 • gateway selected from said routing information upon receiving the routing infonnation from th, 

14 redirect server; 

1 5 e) upon proxying the call setup request by the at least one proxy server to th 

1 6 selected destination gateway, waiting for a response at the at least one proxy server from tb 

17 selected destination gateway; 

^ a f) upon said at least one proxy server receiving the response from the selectc 

. 1 9 destination gateway within a predetermined time, establishing a communication session usir 

20 said selected destination gateway; and 

21 g) if the response is not received within the predetermined time, sending the 

22 call setup request to a succeeding destination gateway selected from the routing information 

20 
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1 . 2. The method as claimed in claim 1 . further comprising repealing steps (d) to (g) 

2 until a destination gateway is determined to be available for establishing said communication 

3 session or until all destination gateways from said routing information have been determined to 

4 be unavailable. 

1 3 , The method of claim 1 , ftortber comprising the steps of: 

2 • recording a destination gateway status as unavailable if response from said 

3 destination is not received within the predetennined time; and 

4 recording a destination gateway status as unavailable if the response from said 

5 selected destination indicator the destination gateway is unavailable. 

1 4. The method as claimed in claim 3, wherein said step of recording records 

2 said destination gateway status as out-of-service in a gateway information table stored within 

3 the RS. 

1 5. The method as claimed in claim 1 , wherein said step of receiving a call setup 

2 request at the at least one proxy server from a source user agent includes the step of addressing 

3 said call setup request to a proxy address of the at least one proxy server. 

. 1 6. The method as claimed in claim 1. wherein said step of receiving a call setup request 

2 at the at least one proxy server from a source user agent includes the step of counting a number 

3 of received requests subsequent to said call setup request at the at least one proxy server. 
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1 7. The method as claimed in claim K wherein rhe at least one proxy server 

2 comprises a Session Iniiiaiion Protocol (SIP) proxy server. 

1 8. The method as claimed in claim 1 , wherein the at least one proxy server 

2 comprises an H.323 gatekeeper. 

1 9. The method as claimed in claim 1 , wherein said step of responding lo the 

2 forwarded call serap request from said at least one proxy server received at the RS includes 

3 determining the stams of a group of destination gateways. 

1 10. The method as claimed in claim 9, wherein the stams of each of said group or 

2 destination gateway is one of in-service and out-6f-service. 

1 n. The method as claimed in claim 10, wherein if the destination gateway status is 

2 recorded as out-of-service in a gateway information table and its associated time value is greater 

3 tlian a current absolute RS time, the gateway address is not added to a routing list of said routing 

4 information. 

1 12. The method a<5 claimed in claim 10. wherein if the destination gateway status is 

2 recorded as out-of-service in a gateway information table and its associated time value is less 

3 than or equal to the current absolute RS time, the gateway address is added to a routing list ol 

4 said routing information and recorded as in-service. 
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1 13. The method as claimed in claim 10. further including ihe siep of sending a 

2 message from tbe RS to a network manager lo record the status of a destination gateway. 

1 14. The method as claimed in claim I . further comprising the steps of forwarding a 

2 request failure response to the source user agem upon receiving the request failure response froifa 

3 the at least one proxy server, and terminating the communication session. 

1 1 5. The method as claimed in claim 1 , fiirther comprising the step of re-sending tht 

2 call semp request to the selected destination gateway a predetermined number of times when th< 

3 response is not received within the predetermined time. 
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1 1 6. A system for allowing a call to be completed in a communication, session between 

2 a calling party and a called party, which comprises: 

3 . a first telephony system including at least one service user agent (SUA); 

4 a second telephony system including at least one destination user agent (DUA); = 

5 an IP network connected between said first and second telephone systems, 

6 a plurality of ingress gateways for interfacing said IP network to said first 

7 telephony system; 

8 a plurality of egress gateways for interfacing said IP network to said second 

9 telephony system; 

^0 an IP telephony proxy server for selecting one of said plurality of egress 

1 1 gateways for completing said call; 

12 an IP redirect server for providing routing information to said IP telephony 

1 3 proxy server, and 

14 a network management system for receiving and storing status changes of 

1 5 destination gateways, said network management system being in communication with said IP 

16 redirect server. 

1 1 7. The system as claimed in claim 1 6. wherein the IP telephony proxy server is a 

2 Session Initiation Protocol (SIP) proxy server. 

1 1 8. The system as claimed in claim 1 6, wherein the IP telephony proxy server 

2 is an H.323 gatekeeper. 
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1 19. A meihod for detecting an available desiination gateway from a plurality of 

2 destination gateways in an IP network for completing a communication session between a calling 

3 party and a called party, said method comprising the steps of: 

4 a) transmitting a message to one of said plurality of destination gateways . 

5 from a server to ascertain an availability status of said one of said plurality of destination 

6 gateways; 

7 - b) waiting for an acknowledge response from said one of said plurality of 

8 destination gateways for a predetennined period of time; 

9 c) determining if said one of said plurality of destination gateways is 

1 0 available if said acknowledge response is received within said predetennined period of time and 

1 1 indicates that the destination gateway is available; and 

12 d) . iransminmgsaidmessagetoasucceedinggateway of said plurality of , 

13 destination gateways. 

1 20. The method as claimed in claim 1 9, fiirther comprising repeating steps (b) to (d) 

2 until the availability status of each of said plurality of destuiation gateways has been determined. 

1 21 . The method according to claim 1 9, wherein if said acknowledge response is not 

2 received within a predetermined period of time, said availability status of said destination 
. 3 gateway is said to be out-of-service. 
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1 22. The method according lo claim 19. ^vhereia if said one of said plurality 

• J • -/J T« k» ivniiahle then sMd availabiliiv status is determinec 

2 destination gateways is determined to be available, men saia a ai» 

3 be in-service. 
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